@Chinex-Boroja Typically, your tests should have more descriptive names. This will help define the scope of your test and make its purpose more apparent. You can follow a structure like given_when_then or subjectUnderTest_actionOrInput_expectedResult.

@Chinex-Boroja Manually adding the framgment here, does not fully capture the intent of testing. When you manually add the fragment, it’s almost guaranteed that it will be added, which may not provide much value in terms of testing.

The test would be more meaningful if it verified that the fragment was added as part of the actual UI flow, triggered by user interaction or lifecycle events, rather than by directly invoking the fragment transaction in the test. This way, the test would better reflect real-world scenarios and provide more meaningful insights.

If you need more clarifications, I am happy to huddle.
CC: @wbrunette what are your thoughts?

@Chinex-Boroja From what I can see, this test is checking that when a user clicks on an item, the app attempts to start the TableDisplayActivity. However, since this test is already within the context of TableDisplayActivity, it feels a bit redundant. Could you share your thoughts on this approach and the reasoning behind it?

Typically, when you're testing within the context of an activity, you wouldn't use the same activity instance to verify actions triggered within it. It might be more effective to verify the intended behavior by confirming what the code is expected to do and validating against that.

CC: @wbrunette

@Chinex-Boroja a more descriptive name here too

Noted @Lamouresparus, will make a fix